SGI Freeware 1998 June

home *** CD-ROM | disk | FTP | other *** search

/ SGI Freeware 1998 June / SGI Freeware 1998 June.iso / dist / fw_ATxgopher.idb / usr / freeware / doc / xgopher / Porting.z / Porting

Wrap

Text File | 1998-01-21 | 11.3 KB | 283 lines

Installing Xgopher on host computer ----------------------------------- This document describes some of the problems that have been reported to me when installing Xgopher on different computer systems. I have included as complete a description of the problem and its solution as I can. In most cases I do not have access to these other systems and can only report second-hand information. There are sections below for Sun,Hewlett-Packard and other machines. In another section, "Personal testing" I list the machines on which I have personally compiled and tested Xgopher. Headings in this file: ---------------------- Sun: Solaris 2.1 Sun Sun: Open Windows Hewlett-Packard Interactive(SunSoft) Unix 3.0 (with Interactive's X11R4 2.0) Dell's R4, 2.2 Personal Testing Sun: Solaris 2.1 ---------------- If you receive unresolved externals from the loader including routines as socket, connect, and others, you need to add the option "-lsocket" to the Imakefile. If you are missing the routines inet_addr, gethostbyname, and gethostname, then you need to add "-lnsl". The place to do this is on the line the distributed Imakefile that reads EXTRA_LIBRARIES = -lm change this to EXTRA_LIBRARIES = -lm -lsocket -lnsl This line is also commented out in a block with others. You need to remove the comments. Don't forget to run xmkmf again to rebuild the Makefile! [ According to Ian MacPhedran: Compiled fine for me with both X11R5 and OpenWindows 3.x. Notes: Requires both -DSYSV and -DSVR4 When compiling under OpenWindows, I required linking to extra libraries: -lsocket -lnsl ] I want to thank Ian MacPhedran <macphed@dvinci.usask.ca> and Edwin Allum <edwin@csri.toronto.edu> for the Solaris port. Sun --- "Cannot connect to host" messages. These are the result of Xgopher not finding the correct name resolver to convert a host name such as gopher.uiuc.edu into an internet address as 128.174.33.160. I have had some people say that they need to use -lresolv on the load command to get Xgopher to work, and others that insist that -lresolve NOT be used since then Xgopher will use the NIS name server for resolving the address. If using or omitting -lresolve works for you, great. Unfortunately, though, this probably is not the solution that will help you. For a full discussion of the problem and recommended solutions, see the document "Sun-names" included with the Xgopher distribution. Sun: Open Windows ---------------- This section applies mostly to people trying to compile Xgopher with Sun's OpenWindows, Release 3. If you use MIT's X11R5 distribution most of these problems will not affect you. You cannot compile Xgopher with Sun's OpenWindows, Release 2. There are two problems you are likely to encounter besides those addressed in the README file. One is the "connect" problem mentioned in the previous section. If you have compiled Xgopher with OW3, but are executing Xgopher with remote display to another system, then you are not executing the Sun-supplied script "openwin" ($OPENWINHOME/bin/openwin). Therefore, some environment variables are not set which may be needed to let X (OW3) find the app-defaults resource file. Try adding the following line to one of your startup files. This is for csh, a slightly different syntax is used for sh. setenv XFILESEARCHPATH $OPENWINHOME/lib/%T/%N%S In fact, the following value is suggested in the "Frequently Asked Questions" list of the Sun system managers news group in the internet (using sh syntax!): XFILESEARCHPATH=$OPENWINHOME/lib/%T/%N%S:/usr/lib/X11/%T/%N%S export XFILESEARCHPATH If you use X11R5, you might instead want /usr/lib/X11/%L/%T/%N%C%S: /usr/lib/X11/%l/%T/%N%C%S: /usr/lib/X11/%T/%N%C%S: /usr/lib/X11/%L/%T/%N%S: /usr/lib/X11/%l/%T/%N%S: /usr/lib/X11/%T/%N%S: $OPENWINHOME/lib/%T/%N%S (put all this on one line, though, with no spaces!) Xgopher cannot find its application resources (defaults) file. If you have installed the resources file in a non-standard location, read this. The above solution will also work, but this is a nice description. (Thanks to R.Stewart(Stew) Ellis for identifying this solution.) The startup routine for OW3 shipped by Sun sets XFILESEARCHPATH. This is set in the shell script "openwin" stored in the bin directory of $OPENWINHOME. The default value is $OPENWINHOME/lib/%T/%N%S. If you store your X application defaults files (e.g., Xgopher.ad) somewhere else, like in the X11R5 tree, you'd better have XFILESEARCHPATH also indicate that directory. For example, if your files are stored under /usr/local/X11R5/lib/X11, you can add this directory to your search path. One way to do this is by putting the following setenv into your .login file before starting OpenWindows: setenv XFILESEARCHPATH /usr/local/X11R5/lib/X11/%T/%N%S (X will normally change the %T value above to "app-defaults".) Hewlett-Packard --------------- If you have trouble linking Xgopher, it may be that some functions are getting loaded from libPW.a. The xmkmf may be adding libPW.a (-lPW) to the Makefile load library list. You should remove the reference to -lPW. I don't think that libPW.a is needed by Xgopher. Here is a helpful news posting explaining the problem that was provided to me by <hardy@golem.ps.uci.edu>: +-----------------------------------------------------------------------------+ ! Date: 8 Dec 92 15:35:33 GMT ! ! References: <1992Dec6.205954.1835@lub001.lamar.edu> ! ! Sender: gcagle@dracula (Greg Cagle) ! ! Reply-To: greg_cagle@mentorg.com ! ! Organization: Mentor Graphics ! ! Lines: 23 ! ! Nntp-Posting-Host: dracula.mentorg.com ! ! ! ! Try man regcmp: ! ! ! ! regcmp and regex are kept in /lib/libPW.a, and are linked by using the! ! -lc and -lPW options to the ld or cc command. See WARNINGS below. ! ! ... ! ! ! ! WARNINGS ! ! regcmp and regex are kept in /lib/libPW.a. Unfortunately, ! ! /lib/libPW.a also contains some functions that have the same names as ! ! functions contained in the default C library, /lib/libc.a. To prevent! ! unexpected results due to these name conflicts, always search libc ! ! before searching libPW. This is done with the ld (or cc) command line! ! option sequence -lc -lPW which satisfies all standard C functions ! ! from libc then searches libPW for the regcmp and regex functions ! ! (there is also an implied -lc following the explicit -lPW to satisfy ! ! any additional C functions required by regcmp and regex). ! ! ! ! - Greg ! ! --------------------------------------------------------------------------- ! ! Greg Cagle Mentor Graphics Corporation ! ! greg_cagle@mentorg.com Platform Technology Division ! ! (503)685-1570 ! +-----------------------------------------------------------------------------+ Interactive(SunSoft) Unix 3.0 (with Interactive's X11R4 2.0) ------------------------------------------------------------ Xgopher 1.3 (beta) was instlled by Sinisa Novosel (sinisa@thphys.irb.hr) on an ISC Unix system. I have included #ifdef's in the Xgopher source based on Sinisa's experience. The following changes should also be made: 1) One nasty thing should be done: in file /usr/include/X11/Intrinsic.h , line #36 (#include <X11/Xos.h>) should be commented-out. 2) add -DISCX into Imakefile ('DEFINES' field) Thanks for this port to: - Sinisa Novosel, SysAdm, Institute Rugjer Boskovic, Croatia, Zagreb,- - dep. Theor.Physics - - sinisa@thphys.irb.hr Dell's R4, 2.2 -------------- Notes from Joseph Urban (jurban@norden1.com): Uncomment the EXTRA_LIBRARIES line near the top of the Imakefile and add -lresolv and -lucb to EXTRA_LIBRARIES in addition to the -lm. 3B2 --- Xgopher has been run on this machine, but not by me. Bob Tracy -- btracy@sacdm10.kelly.af.mil (ROBERT C. TRACY - RCF/SCOOP) -- made the following offer: > If you wish, feel free > to mention me as a contact point for fellow 3B2 die-hards that are > trying to get "xgopher" working :-). N.B.: my comments apply to the > WE32000 chipset, not the newer RISC 3B2. Personal Testing ---------------- I have had access to and have been able to compile and execute Xgopher on the following platforms. Each one gave a clean compile with no warnings using the default imake that is provided with the version of X indicated. The exception is the build with OpenWindows 3 on a Sun which required the work-arounds mentioned in the README file. . IBM RS/6000 model 220 and other models running AIX 3.2.1 client: MIT's X11R5 X server: IBM's AIXWindows 1.2.1 NOTE: (If you compile with IBM's X11R4 you may still need to compile the Athena widget library yourself. Compile all the stuff under /usr/lpp/X11/Xamples, or just that library.) . Sun 4 (SparcStation) running SunOS 4.1.2 client: MIT's X11R5 X server: Sun's OpenWindows 3 and remote display client: Sun's OpenWindows 3 X server: Sun's OpenWindows 3 and remote display . Sun 4 (SparcStation) running Solaris 2.1, with /usr/ucb/cc compiler client: Sun's OpenWindows 3 X server: remote display . Sequent running Dynix 3.1.1 (a BSD-derived system) client: MIT's X11R5 - libraries and client compiled with gcc X server: display to remote machine . Intel 486/33 running BSD/386 1.0 from BSD, Inc. client: MIT's X11R5 - libraries and client compiled with cc (gcc) X server: X386 and a proprietary X386 server for high performance . Convex running ConvexOS (Unix) client: MIT's X11R5 X server: display to remote machine . Silicon Graphics IRIS-4D running IRIX 4.0.1 client: Whatever SGI supplied (X11R4 variant) X server: display to remote machine . Various X servers have been tested including IBM X terminals. Feedback -------- Please! If you find portability problems in Xgopher, report them to me by e-mail (Allan Tuchman, a-tuchman@uiuc.edu). I do not read news often enough and some of the articles age off the system before I see them. Any portability problems reported to me are normally fixed in the next release.